I am not familiar with Cython. Is it correct that the result depends on the CPython runtime? Is that limiting us on which interpreter our code works?

I have recently read about pybind11. Maybe that would be another alternative to consider.

@dirk-thomas Yes, it limits us to the cpython interpreter. Cython generates C code that uses the CPython extension API. It also supports pypy because pypy implements a subset of that. The current state and pybind11 have the same interpreter limitation for the same reason.

I can look into pybind11 and make a list of pros and cons

The current state and pybind11 have the same interpreter limitation for the same reason.

Thanks for the clarification.

I can look into pybind11 and make a list of pros and cons

That would be great.

In general, I'm in favor of using something that generates code and reduces the burden of python binding maintenance for us. Off the top of my head, it is probably worth surveying Cython, pybind11, boost::python, and SWIG for this purpose, and seeing which fits in with our goals the best.

@dirk-thomas comparison to pybind11 in #173

@clalancette I think boost::python can be skipped since pybind11 is a header only fork-ish of it. I think it is safe to assume pybind11 has all of the advantages without the overhead of installing boost.

Thanks @sloretz for putting this together.

Agreed regarding the statement about pybind11 over boost::python. Some sugar from boost::python is not available in pybind11 but it's very c++ specific and shouldn't impact us for C bindings.
I used pybind11 recently in other projects and it was a good experience, actually more intuitive than boost::python and pretty feature complete.
I haven't played with SWIG but it could be interesting to add it to the comparison to make an educated decision.

I will close this for now since it seems pybind11 is most likely, but I will wait to delete the branch until that is confirmed.